Le projet Mono, framework open source destiné à la mise en œuvre de la plateforme de développement .NET de Microsoft dans des environnements autres que Windows, aurait-il trouvé son ultime refuge ? Microsoft, qui assurait la maintenance du projet depuis le rachat de Xamarin en 2016, vient d’annoncer son transfert à WineHQ, l’équipe en charge du développement de Wine.
« Nous tenons à souligner que le projet Mono a été la première implémentation de .NET sur Android, iOS, Linux et d’autres systèmes d’exploitation », salue Microsoft dans un message publié sur le site dédié, avant de rappeler que l’activité du projet s’est considérablement ralentie, victime indirecte de l’évolution des environnements de développement multiplateformes. La dernière version majeure remonte en effet à 2019, et Mono ne reçoit plus depuis que des correctifs, dont le dernier a été diffusé en février dernier.
Dans le cadre de ce transfert, WineHQ assure donc maintenant la responsabilité du projet, dont les sources sont disponibles sur son Gitlab, tandis que les dépôts et binaires historiques devraient quant à eux être archivés. Dans la mesure où WineHQ, comme Microsoft, exploitent déjà chacun leur propre fork, plus moderne, de Mono, l’intendance ne devrait revêtir qu’une portée symbolique.
Lancé en 2001 par Miguel de Icaza (par ailleurs créateur de GNOME), Mono a connu une histoire tumultueuse, sur fond de rachats successifs et de controverses liées à de potentielles atteintes aux droits de la propriété intellectuelle de Microsoft, bien avant que ce dernier ne prenne la décision d’ouvrir .NET à l’open source.
Commentaires (36)
#1
#1.1
#1.2
#1.5
#1.6
#1.3
#1.4
#2
#2.1
Historique des modifications :
Posté le 29/08/2024 à 17h56
1
#2.2
#2.10
#2.3
Des applications multiplateformes sont portées sous linux comme l'émulateur Ryujinx.
Mono est fourni avec wine (wine-mono) tout comme wine-gecko pour remplacer les closedsource .net (< 5.0) et ie.
Microsoft avec Azure Linux doit l'utiliser.
#2.4
#2.5
Mais c'est le cas aussi du logiciel de sauvegarde Duplicati.
#2.9
#2.8
#2.11
#2.6
#2.7
Comme containeriser une VM pour faire croire qu'une appli monolithique de l'enfer est subitement "cloud native" ?
#2.12
Au passage, un pod ne peut pas utiliser la puissance de calcul d'un cluster entier, un pod ne peut jamais excéder la capacité disponible du nœud sur lequel il tourne (dans un scénario où tu n'aurais pas toi-même mis des limites à la consommation de ressources du pod)
J'ai déjà eu un client avec ~200 microservices en .Net dans ce type de scénario.
La bonne pratique n'est pas de convertir des VM en pod, juste de déployer les applis dans des images dans un flux ci/cd. On ne gère pas des pods comme des VM et convertir des VM, même si c'est partiellement possible, en dit plus sur la qualité de l'architecture d'une entreprise qu'autre-chose.
#2.13
#2.15
#2.16
Ou encore ceux qui disent "azy t'inquiète" en mettant leur BDD dessus et qui ont eu droit à une cellule de crise car ils avaient perdu toutes les données.
À trop prévenir que ça marchera pas, parfois je me dis qu'il vaut mieux les laisser expérimenter le skateboard dans l'escalier.
#2.17
Historique des modifications :
Posté le 30/08/2024 à 17h34
Ah oui, ceux là je les connais bien ces cas là... Mon préféré pour le stockage, c'est le scénario Openshift avec Openshift Data Foundation (du ceph) installé sur de l'Openstack avec volumes cinder sur ceph... parceque l'architecte "cloud" a dit que ... et pour chaque giga utilisé par une application, tu as à minima 9 gigas physiques utilisés grâce à une réplication 3*3... et tu met tout sur des blades HP anémiques et sur du SAS parceque tu as claqué ton budget sur la partie logicielle... et ensuite arrive un projet qui a besoin de faire tourner une DB en HA DR, et là tu les laisse faire l'import des données de 2To et tu vas te faire un sandwich ... et par se faire un sandwich je ne parle pas juste de prendre un pain et de le garnir, ni même de pétrir la pâte à pain, de la laisser lever et avant de la cuire, mais de commencer l'exercice en semant les blés.
#2.14
#2.18
Historique des modifications :
Posté le 04/09/2024 à 17h11
Ils avaient pas prévu d'appeler .Net Core "Mono Nucléos", mais ont renoncé pour une raison marketing.
#3
#3.1
Après, c'est loin d'être étonnant. .Net Core (ou .Net 5 et supérieur) est la seule version de .Net encore en développement. Et cette version est portable.
Le .Net framework (dont la version officielle était limité à Windows) s'est arrêté en 4.8 et il n'y aura pas d'autres versions.
Mono n'a donc guère d'intérêt à continuer aujourd'hui.
#3.2
Le mono, même en Core, mais c'est d'un ringard !...
#3.3
#4
#4.1
Ce sont deux projets distincts, bien qu'ils présentent de nombreuses similarités. L'adoption de CoreCLR (qui est portable) comme implémentation de référence .Net par Microsoft a simplement rendu Mono "quasiment désué" (Mono était très utile par sa portabilité, devenue "inutile" avec CoreCLR car déjà présente).
#4.2
Malheureusement ... ils l'ont cassé 3 fois minimum: dotnet 4, dotnet core, dotnet 6.
Soit carrément sur le format d'objet, soit sur la lib.
C'est carrément l'enfer si vous pensez que .net standard est utilisable dans les 2 mondes (core et framework): c'est vrai, du moment que vous ne faites pas de chargement à la volée. Car dans ce cas, vous allez mixer au pif des objets des 2 environnement d'exécution et les liens ne se feront pas...
Bref, c'est bien, les langages sont cool, les possibilités intéressantes, les outils déments, mais plein de promesses ne sont pas tout à fait tenues, on est loin de java "write once, run everywhere".
Sans compter qu'ils n'ont pas su le pousser assez pour aller vers du platform agnostic, notamment au moment de swindows phones.
#4.3
(Faites pas gaffe, j'y pige que chique en programmation... Vous pourriez me dire que que Macron a été conçu en .NET par Brigitte, que ce serait du pareil au même...)
(Tout ça, juste pour avoir l'air d'exister... De plus en plus navrant... Désolé... )
Historique des modifications :
Posté le 30/08/2024 à 20h39
Allons bon... Du coup, j'ai enlevé mon pouce en l'air à @teddyalbina, non mais !
(Faites pas gaffe, j'y pige que chique en programmation... Vous pourriez me dire que que Macron a été conçu en .NET par Brigitte, que ce serait du pareil au même...)
(Tout ça, juste pour avoir l'air d'exister... De plus en plus navrant... Désolé... )
#5
#5.1